UCF STIG Viewer Logo
Changes are coming to https://stigviewer.com. Take our survey to help us understand your usage and how we can better serve you in the future.
Take Survey

PostgreSQL must produce audit records containing sufficient information to establish the outcome (success or failure) of the events.


Overview

Finding ID Version Rule ID IA Controls Severity
V-72843 PGS9-00-000200 SV-87495r2_rule Medium
Description
Information system auditing capability is critical for accurate forensic analysis. Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the system. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.
STIG Date
PostgreSQL 9.x Security Technical Implementation Guide 2018-02-27

Details

Check Text ( C-72977r2_chk )
Review locations of audit logs, both internal to the database and database audit logs located at the operating system level. 

Verify there are appropriate controls and permissions to protect the audit information from unauthorized modification. 

Note: The following instructions use the PGDATA environment variable. See supplementary content APPENDIX-F for instructions on configuring PGDATA. 

#### stderr Logging 

If the PostgreSQL server is configured to use stderr for logging, the logs will be owned by the database owner (usually postgres user) with a default permissions level of 0600. The permissions can be configured in postgresql.conf. 

To check the permissions for log files in postgresql.conf, as the database owner (shown here as "postgres"), run the following command: 

$ sudo su - postgres 
$ grep "log_file_mode" ${PGDATA?}/postgresql.conf 

If the permissions are not 0600, this is a finding. 

Next, navigate to where the logs are stored. This can be found by running the following command against postgresql.conf as the database owner (shown here as "postgres"): 

$ sudo su - postgres 
$ grep "log_directory" ${PGDATA?}/postgresql.conf 

With the log directory identified, as the database owner (shown here as "postgres"), list the permissions of the logs: 

$ sudo su - postgres 
$ ls -la ${PGDATA?}/pg_log 

If logs are not owned by the database owner (shown here as "postgres") and are not the same permissions as configured in postgresql.conf, this is a finding. 

#### syslog Logging 

If the PostgreSQL server is configured to use syslog for logging, consult organization syslog setting for permissions and ownership of logs.
Fix Text (F-79285r5_fix)
Using pgaudit PostgreSQL can be configured to audit various facets of PostgreSQL. See supplementary content APPENDIX-B for documentation on installing pgaudit.

All errors, denials and unsuccessful requests are logged if logging is enabled. See supplementary content APPENDIX-C for documentation on enabling logging.

Note: The following instructions use the PGDATA and PGVER environment variables. See supplementary content APPENDIX-F for instructions on configuring PGDATA and APPENDIX-H for PGVER.

With pgaudit and logging enabled, set the following configuration settings in postgresql.conf, as the database administrator (shown here as "postgres"), to the following:

$ sudo su - postgres
$ vi ${PGDATA?}/postgresql.conf
pgaudit.log_catalog='on'
pgaudit.log_level='log'
pgaudit.log_parameter='on'
pgaudit.log_statement_once='off'
pgaudit.log='all, -misc'

Next, tune the following logging configurations in postgresql.conf:

$ sudo su - postgres
$ vi ${PGDATA?}/postgresql.conf
log_line_prefix = '< %m %u %d %e: >'
log_error_verbosity = default

Last, as the system administrator, restart PostgreSQL:

# SYSTEMD SERVER ONLY
$ sudo systemctl reload postgresql-${PGVER?}

# INITD SERVER ONLY
$ sudo service postgresql-${PGVER?} reload